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(54) Computer system and method for executing network mobile code with reduced run-time 
memory space requirements 



(57) A client computer system and associated meth- 
od in a computer network over which are provided pro- 
grams with methods. The client computer is capable of 
executing the programs with reduced run-time memory 
space requirements. Specifically, a network communi- 
cations interface receives the methods of the programs 
and a network communications manager loads uncom- 
pressed in available space in the run-time memory the 
methods when they are received. An execution control- 



ler controls execution of the programs so that the meth- 
ods are invoked and not invoked at various times during 
execution of the programs. A compressor compresses 
in the memory compressible ones of the uncompressed 
methods that are not invoked so that space is made 
available in the run-time memory. The compressor also 
decompresses in available space in the run-time mem- 
ory decompressive ones of the methods so that they 
may be invoked. 
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Description 

The present invention relates to computer systems 
and methods for executing programs with reduced run- 
time memory space requirements. In particular, the 
present invention pertains to computer systems and 
methods in a network for executing code transmitted 
over the network (i.e., network mobile code) so that the 
run-time memory space requirements of the code is re- 
duced. 

BACKGROUND OF THE INVENTION 

Computer systems are now being built or config- 
ured to take advantage of properties of programs whose 
code is in an architecture neutral (AN) binary format, 
hereinafter referred to as AN code. Thus, the AN code 
of these programs is independent of the specific archi- 
tecture or platform of the computer system. 

The term architecture is defined for the purposes of 
this document to mean the operating characteristics of 
a family of computer models. Examples of specific ar- 
chitectures include Macintosh computers, IBM PC com- 
patible computers using the DOS or Windows operating 
systems, Sun Microsystems computers running the So- 
laris operating system, and computer systems using the 
Unix operating system. 

The term architecture specific (AS) is defined for the 
purposes of this document to refer to the requirement 
that the code of certain programs be in a binary format, 
hereinafter referred to AS code, for execution only on 
computer systems with a specific computer architec- 
ture. Thus, programs with code written in a conventional 
programming language (e.g., C language) and compiled 
for a specific architecture (e.g., IBM compatible PC) can 
only run on that architecture or emulators of that archi- 
tecture. 

The term architecture neutral (AN) is defined for the 
purposes of this document to refer to programs whose 
compiled code can be executed on a variety of computer 
systems with different architectures. For example, a 
computer system with a specific architecture can be 
configured with a Java (a trademark of Sun Microsys- 
tems) virtual machine module. The Java virtual machine 
module enables execution of programs with code writ- 
ten in the Java programming language and compiled in- 
to bytecode, hereinafter referred to as Java bytecode, 
for the instruction set of the Java virtual machine. Java 
bytecode is independent of the specific architecture of 
the computer system. 

Important features of programs with AN code in- 
clude their portability. For example, since programs in 
AN code can be executed on any computer system con- 
figured to execute the AN code regardless of the com- 
puter system's specific architecture, these programs 
can be easily transported over a network from one com- 
puter system to another. For example, programs com- 
piled into Java bytecode can be executed on any com- 



puter system with a Java virtual machine module and 
can be easily transported over a network from one com- 
puter system to another using a Hot Java (a trademark 
of Sun Microsystems) network communications manag- 

5 er. 

Furthermore, another important feature related to 
the portability of programs compiled into Java bytecode 
is the verifiability of such programs. Specifically, the 
Java virtual machine module can easily verify that these 

10 programs satisfy predefined integrity criteria. Such in- 
tegrity criteria Include stack and data type usage restric- 
tions that ensure that Java bytecode cannot overflow or 
underflow the Java virtual machine module's stack and 
that all instructions in Java bytecode utilize only data 

f5 whose data type matches the data type restrictions for 
those instructions. As a result, a program in Java byte- 
code cannot forge object pointers and generally cannot 
access system resources other than those which the us- 
er has explicitly granted it permission to use. 

6 For these reasons, computer systems are being 
configured for execution of programs in AN code that 
are received over a network. In fact, in some cases, such 
computer systems may not even require a secondary 
memory (e.g., a hard disk) since the programs are load- 

25 ©d directly into the run-time (i.e., execution-time) mem- 
ory (e.g., random access memory (RAM)) of the com- 
puter system. As a result, the user of such a computer 
system is freed from the cycle of software purchase, in- 
stallation, configuration and upgrade that is currency 

30 typical of software products. 

The just described features of AN code make it par- 
ticularly attractive for use with small or cheap computer 
systems that are networked and are loaded with AN 
code on demand. For example, these kinds of computer 

35 systems may be video games, personal digital assist- 
ants (PDAs), cellular phones, or other similar computer 
systems or computer operated devices. 

Unfortunately, however, programs in AN code run 
slower than the same programs in AS code. For exam- 

40 pie, programs in Java bytecode executed by a Java vir- 
tual machine module typically run 2.5 to 20 times as slow 
as the equivalent program in AS code. Thus, a user of 
a computer system may find it desirable to receive over 
a network AS code of a program so that the AS code 

45 can be executed on the specific architecture of the com- 
puter system. However, to ensure that these programs 
are securely shipped to a computer system, the network 
would have to be closed or trusted or these programs 
have to have embedded digital signatures which can be 

50 verified. 

Moreover, AS code which has been generated from 
AN is much larger than the original AN code. For exam- 
ple, AS code generated from Java bytecode is typically 
2 to 5 times the size of the Java bytecode. Thus, a fixed 
55 amount of run-time memory can hold substantially less 
compiled AS code than AN code. However, as men- 
tioned previously, AS code is much faster than AN code 
irom which it is generated and may be the only way to 



5DOCID: <EP 0811911A2J_> 



2 



EP0 811 911 A2 



achieve adequate performance. 

In the just described computer systems, price is ex- 
tremely important. In practice, one of the most signifi- 
cant costs in building such computer systems is the 
amount of run-time memory that is required for execu- s 
tion of loaded programs. It is therefore very important to 
reduce the amount of run-time memory required by 
these computer systems since such a reduction produc- 
es a strong competitive advantage. 

Furthermore, in the computer systems of the type 10 
described above, it may not be possible to page to sec- 
ondary memory. In this case, the AN or AS code re- 
ceived over a network could be cached in the run-time 
memory and flushed when its space in the run-time 
memory is required. However, when execution of the is 
flushed program is to be continued, the original code 
must again be downloaded over the network. This sig- 
nificantly affects the execution speed of the program. 
Furthermore, even in computer systems where it is pos- 
sible to page to secondary memory, the time required to 20 
retrieve the code from the secondary memory may be 
too costly. 

In the present invention, compression and then de- 
compression of the code of a program received over a 
network is used to reduce the storage cost of the code 2s 
in the run-time memory. Since this is much faster than 
flushing code and retrieving it, the execution speed of 
the code is not significantly affected by compression and 
decompression. 



SUMMARY OF THE INVENTION 

In summary, the present invention is a client com- 
puter system and associated method in a computer net- 
work over which are provided programs with methods. 
The client computer is capable of executing the pro- 
grams with reduced run-time memory space require- 
ments. The client computer system comprises a run- 
time memory, a communications interface, a network 
communications manager, an execution controller, and 
a compressor. 

The network communications interface receives the 
methods of the programs and the network communica- 
tions manager loads uncompressed into available 
space in the run-time memory the methods when they 
are received. The execution controller controls execu- 
tion of the programs so that the methods are invoked 
and not invoked. 

The compressor compresses in the run-time mem- 
ory compressible ones of the compressed programs 
that are not invoked. As a result, space is made availa- 
ble in the run-time memory. The compressor also de- 
compresses in available space in the run-time memory 
decompressible ones of the compressed methods so 
that they may be invoked. 

In one embodiment, the compressor decompresses 
the decompressible ones of the compressed methods 
as soon as they are invoked. 



In another embodiment, the compressor decom- 
presses the decompressible ones of the compressed 
methods after a predetermined time interval. 

In still another embodiment, the compressor com- 
presses the compressible ones of the uncompressed 
methods as soon as they are no longer invoked. 

In yet another embodiment, the compressor com- 
presses the compressible ones of the uncompressed 
methods when space in the run-time memory is needed 
but not available. Moreover, in this embodiment, the di- 
ent computer system may further comprise a least re- 
cently invoked list that lists those of the methods that 
are currently not invoked in order of least recently in- 
voked method to most recently invoked method. As a 
result, the compressible ones of the uncompressed 
methods are the least recently invoked methods In the 
least recently invoked list when space in the run-time 
memory is needed but not available. 

In yet still another embodiment, the compressor 
flushes from the run-time memory flushable ones of the 
compressed methods when space in the run-time mem- 
ory is needed but not available. 

As an alternative to the previous embodiment, the 
dient computer system may further comprise a second- 
ary memory. In this case, the compressor stores in the 
secondary memory storable ones of the compressed 
methods when space in the run-time memory is needed 
but not available. Then the compressor retrieves from 
the secondary memory retrievable ones of the com- 
pressed methods that are to be decompressed. 

BRIEF DESCRIPTION OF THE DRAWINGS 



Examples of the invention will be described in con- 
35 junction with the drawings, in which: 

Figure 1 is a block diagram of a client computer sys- 
tem incorporating the present invention. 

Figure 2 is a functbnal block diagram of the opera- 
tion of the client computer system. 

Figure 3 is a flow chart of the compression method 
of the client computer system. 

Figure 4 is a flow chart of the decompression meth- 
od of the client computer system. 

Figure 5 shows an alternative embodiment of the 
4 $ client computer system. 

Figure 6 shows a functional block diagram of the 
operation of the alternative embodiment of the client 
computer system. 

*> DETAILED DESCRIPTION OF THE INVENTION 

Referring to Figure 1, there is shown a computer 
network 100 in accordance with the present invention. 
It includes one or more client computer systems 102, 
s 5 one or more server computer systems 1 04, and a net- 
work communications connection 106. 

The client computer systems 102 are connected to 
the server computer systems 104 via the network com- 
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munications connection 106. The network communica- 
tions connection may be a local or wide area network, 
the Internet, or some other type of network communica- 
tions connection. 

Each server computer system 104 includes a cen- 
tral processing unit (CPU) 110, a user interface 112, a 
network communications interface 116, and a memory 
118: The network communications interface enables 
each server computer system to communicate with the 
client computer systems 102 via the network communi- 
cations connection 106. 

The memory 118 of each server computer system 
104 stores an operating system 1 20, a network commu- 
nications manager (or server) 122, and programs 145. 
The operating system and communications manager 
are all run on the CPU 1 20. The operating system con- 
trols and coordinates running of the network communi- 
cations manager in response to commands issued by a 
user with the user interface 112 or received by the net- 
work communications interface 116 via the network 
communications connection 106 from users of the client 
computer systems 102. 

The programs 145 comprise methods 147 and/or 
148. For purposes of this document, any discrete frag- 
ment or portion of a program that is invoked and not in- 
voked at various times during the execution of the pro- 
gram is considered a method. 

The methods 1 47 of each server computer system 
104 contain architecture neutral (AN) code that is inde- 
pendent of the specific architecture (i.e., platform) of the 
client computer systems 1 02. These programs are com- 
piled from a specific programming language into the AN 
code. In the preferred embodiment, these programs are 
written in the Java programming language and compiled 
into Java bytecode. Moreover, these programs are in- 
cluded in object classes with methods that form software 
programs which are programmed in an object-oriented 
manner. 

On the other hand, the methods 1 48 of each server 
computer system contain architecture specific (AS) 
code that is compiled for the specific architecture of the 
client computer systems 1 02. As alluded to earlier, these 
kinds of methods are desirable in that they run faster 
than the same methods in AN code. As will be explained 
in greater detail later, it is preferred that the network 1 00 
be a closed and trusted network in which these pro- 
grams may be securely shipped to the client computers 
102 with a high degree of confidence or that these pro- 
grams have embedded digital signatures which can be 
verified. 

As will also be explained in more detail later, the 
methods 147 and/or 148 are transmitted upon user re- 
quest to the client computer systems 102 using the net- 
work communications manager 122. Thus, the code of 
these methods is considered network mobile code. 

Each client computer system 102 may be a video 
game, a personal digital assistant (PDA), a cellular 
phone, desktop computer, or other computer system or 



computer operated device which requires a small 
amount of runtime memory. Furthermore, each client 
computer system includes a central processing unit 
(CPU) 126, a user interface 128, a network communi- 
s cations interface 132, a read only memory (ROM) 134, 
and a run-time random access memory (RAM) 1 36. The 
network communications interface enables the client 
computer system to communicate with the server com- 
puter systems 104 via the network communications con- 
to nection106. 

The RAM 136 of each client computer system 102 
stores an operating system 1 38, a network communica- 
tions manager 140, a virtual machine module 142, and 
a code compressor 1 46 that have all been loaded from 
is the ROM 1 34. The RAM also stores the programs 1 45 
with methods 147 containing AN code and/or methods 
148 containing architecture specific (AS) code that have 
been downloaded from the server computer systems 
104. The operating system, network communications 
20 manager, virtual machine module, compWei compres- 
sor, and programs are all executed on the CPU 126. The 
operating system controls and coordinates execution of 
the network communications manager, virtual machine 
module, code compiler, code compressor, and pro- 
2$ grams in response to commands issued by a user with 
the user interface 128. 

As alluded to earlier, the methods 147 and/or 148 
are received from the server computer systems 1 04 up- 
on user request. These methods are obtained using the 
30 network communications manager 122 which is, in the 
preferred embodiment, a HotJava network communica- 
tions manager. The network communications manager 
then loads these methods in the RAM 1 36. 

The code verifier 151 of the virtual machine module 
35 1 42 verifies that the AN code of the loaded methods 1 47 
meets predefined integrity criteria. As mentioned earlier, 
this may include stack and datatype usage restrictions 
to ensure that loaded methods cannot overflow or un- 
derflow the virtual machine module's stack and that all 
40 instructions utilize only data whose data type matches 
the data type restrictions for those instructions. In the 
preferred embodiment, the virtual machine module is a 
Java virtual machine module. 

However, in the case of the received methods 1 48 
45 with AS code, the code verifier 151 cannot be used to 
directly verify their integrity. Thus, to verify their integrity 
indirectly, the network 100 may be a closed and trusted 
network in which these methods may be securely 
shipped to the client computers 102 with a high degree 
so of confidence. Alternatively, if the network 1 00 is not se- 
cure, these programs may have embedded digital sig- 
natures which enable the network communications 
manager 140 to verify that they are from a trusted 
source. 

55 The execution controller 1 53 of the virtual machine 
module 142 controls execution of the programs 145. In 
particular, the execution controller interprets the AN 
code of the methods 147 for execution on the specific 
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architecture of the client computer system 102 and en- 
ables these methods to call the methods 1 48 containing 
AS code for execution on the specific architecture, The 
execution 149 data generated during the execution of 
the programs is stored in the RAM 136. In addition, if 
the network communications manager 140, code com- 
piler 144, and/or code compressor 146 are in AN code, 
then the execution controller controls execution of them 
as well. 

Furthermore, in order to keep the RAM space re- 
quirements of the client computer system 102 low, the 
code compressor 146 compresses and decompresses 
in the RAM 1 36 the code of the methods 1 47 and/or 1 48 
at various times. This is done for the methods that are 
compressible and decompressive because they re- 
spectively satisfy predefined compression and decom- 
pression criteria 1 52 and 1 54 that are stored in the RAM 
1 36 and inputted by the user with the user interface 1 28. 
The compression and decompression criteria are more 
fully described later and are. in some embodiments of 
the present invention, usei selectable and/or tunable 
(using the user interface 126} Irom a set of predefined 
memory management strategics 

The storage and invocation status of the methods 
147 and/or 148 is maintained with the method status da- 
ta structures 1 55. The molhod status daia structures are 
updated by the network communications manager 140, 
the execution controller 153 and the code compressor 
146. 

Figure 2 shows a fun~tiona' block diagram of the 
operation of each of the client computer systems 102 in 
compressing and decompressing in the RAM 1 36 the 
methods 147 and/or 148 In addition Figures 3 and 4 
respectively show the preferred compression and de- 
compression methods 300 and 400 

Referring to Figures 1 -3 when a user requests ex- 
ecution of one of the programs 1 45 of one of the server 
computer systems 104, the user's client computer sys- 
tem 102 obtains the requested program Irom the server 
computer system (step 3C2 o( Figure 3). This is done 
when the user issues a command wuh the user interface 
128 to download and execute the program from the 
server computer system. In response, the operating 
system 1 20 calls the network communications manager 
140 which generates a message indicating that such a 
request has been made. The network communications 
interface 1 32 then transmits the message to the server 
computer system. 

The network communications interface 116 of the 
server computer system 104 receives the transmitted 
message. In response, the network communications 
manager 122 of the server computer system provides 
the methods 147 and/or 148 of the requested program 
1 45 to the network communications interface which then 
transmits the methods to the user's client computer sys- 
tem 102. 

The methods 1 47 and/or 1 48 that were transmitted 
are received by the network communications interface 



132 of the user's client computer system 102. In re- 
sponse, the network communications manager 140 
then determines if enough space in the RAM 136 is 
available for loading the received methods (decision 

5 step 304 of Figure 3). If there is, then the network com- 
munications manager loads the code of these methods 
uncompressed into the available space in the RAM (step 
306 of Figure 3). As a result, these methods are loaded 
into the RAM along with previously loaded programs 

10 methods 1 47 and/or 1 48 of other programs 1 45, In load- 
ing these methods, the network communications man- 
ager updates the method storage status table 200 of the 
method status data structures 155 to identify the meth- 
ods and the corresponding pointers to the memory 

15 spaces in the RAM 136 occupied by these methods. 
Furthermore, the network communications manager up- 
dates the program status table to indicate that the code 
of the methods is uncompressed (U). 

The network communications manager 140 than in- 

20 vokes the code verifier 151 of the virtual machine mod- 
ule 142. In response, the code verifier verifies that the 
AN code of any methods 147 that were just loaded 
meets the predefined integrity criteria discussed earlier 
(step 307 of Figure 3). 

25 The program 145 whose methods 147 and/or 148 
were just loaded is then executed under the control of 
the execution controller (step 314 of Figure 3) along with 
any previously loaded programs. As the programs are 
executed, their methods are invoked and not invoked at 

30 various times during their execution. As mentioned pre- 
viously, the execution controller interprets the AN code 
of the methods 147 for execution on the specific archi- 
tecture of the user's client computer system 102 and en- 
ables these methods to call the methods 1 48 containing 

35 AS code for execution on the specific architecture. 

Each of the loaded methods 147 and/or 148 may 
not be invoked at various times because it may have to 
wait for data, may have been put to sleep, etc... When 
the execution controller determines that this has oc- 

^0 curred, it adds the method to the least recently invoked 
(LRI) list 202 of the program status data structures 1 55 
to indicate that it is currently not invoked. The methods 
in the LRI list are listed from most recently invoked to 
least recently invoked. 

45 As indicated earlier, in order to reduce the space 
requirements of the RAM 136, the code of each loaded 
method 147 and/or 146 for which the predefined com- 
pression criteria 152 is satisfied is compressed by the 
code compressor 1 46. In the preferred embodiment, the 

50 compression criteria specifies that the code of a com- 
pressible method 147 or 148 be compressed at the time 
when (1) space in the RAM 136 is needed but not avail- 
able, and (2) the method is the least recently invoked 
method in the LRI list 202 that has not yet had its code 

55 compressed. 

When the network communications manager 140 
determines that space in the RAM 136 is not available 
to load one or more of the methods 147 and/or 148 re- 
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ceived by the server computer systems 104 (decision 
step 304 of Figure 3), then it invokes the code compres- 
sor 146. In response, the code compressor compresses 
the code of the least recently invoked method(s) in the 
LRI list 202 whose code has not yet been compressed 
until enough space has been made available (step 316 
of Figure 3). The code compressor also updates the 
method storage status table 200 to identify the corre- 
sponding pointer(s) to the memory space(s) of the com- 
pressed code of the method(s) and to indicate that the 
code of the method(s) has been compressed (C). The 
network communications manager then loads the meth- 
od^) for which space has been made available into the 
available space, as described earlier (step 306 ol Figure 
3). 

The code compressor 1 46 may use any fast data 
compression technique well known to those skilled in 
the art. Moreover, the code compressor may use sepa- 
rate compression techniques for optimal compression 
of the AN code of the methods 147 and the AS code of 
the methods 148. 

Furthermore, while the loaded methods 147 and/or 
148 are invoked, they generate execution data. For any 
of these methods which the execution controller 1 53 de- 
termines is invoked (decision step 320 of Figure 3) and 
for which space in the RAM 1 36 is available to store ex- 
ecution data (decision step 322), the execution control- 
ler stores the execution data in the RAM (step 324 of 
Figure 3). 

However, for each of the loaded methods 147 and/ 
or 148 which the execution controller 153 determines is 
invoked (decision step 320 of Figure 3) and for which 
space in the RAM is not available but needed to store 
execution data (decision step 322), the execution con- 
troller invokes the code compressor 146. As in the ear- 
lier situations where space in the RAM is needed, the 
code compressor compresses the code of the least re- 
cently invoked method(s) in the LRI list 202 whose code 
has not yet been compressed until enough space has 
been made available (step 326 of Figure 3). And, as de- 
scribed earlier, the code compressor updates the meth- 
od storage status table 200 to identify the corresponding 
pointer(s) to the memory space(s) of the compressed 
code of the method(s) and to indicate that the code of 
the method(s) has been compressed (C). The execution 
controller then stores the execution data in the space 
made available in the RAM (step 324 of Figure 3), as 
described earlier, and execution of the program with the 
method(s) whose execution data was stored continues 
(step 31 4 of Figure 3). 

Moreover, referring to Figures 1, 2, and 4, when 
space in the RAM 1 36 is available, each loaded method 
147 and/or 148 that is compressed and for which the 
predefined decompression criteria 154 is satisfied is de- 
compressed by the code compressor 146. In the pre- 
ferred embodiment, the predefined decompression cri- 
teria 1 54 for decompressing a decompressible method's 
code simply specifies that the code of the method is 



10 

compressed and is to be decompressed at the time 
when the method is to be invoked again. 

Thus, whenever the execution controller 1 53 deter- 
mines that one of the loaded methods 147 and/or 148 

s is to be invoked (decision step 402 of Figure 4), it deter- 
mines whether the code of this method is compressed 
(decision step 404 of Figure 4). This is determined from 
the method storage status table 200. If the method's 
code isn't compressed, then the method is invoked by 

10 the execution controller (step 406 of Figure 4). When it 
is no longer invoked, its code may be compressed by 
the code compressor 146 in the manner described ear- 
lier. 

However, if the code of the method 147 or 148 that 
i& is to be invoked is compressed, then the execution con- 
troller invokes the code compressor 1 46 to decompress 
the method's code. The code compressor determines if 
there is enough space available in the RAM 1 36 to de- 
compress the code (decision step 408 of Figure 4). If 
20 there is enough space available, the code compressor 
decompresses the code in the available space (step 41 0 
of Figure 4). in doing so, it updates the method storage 
status table 200 to identify the corresponding pointer(s) 
to the memory space(s) of the uncompressed code and 
25 to indicate that the method's code is now uncompressed 
(U). 

However, if there is not enough space available, 
then the code compressor 146 compresses the code of 
the least recently executed method(s) in the LR1 Wst202 
30 whose code has not yet been compressed until space 
has been made available (step 41 2 of Figure 4). This is 
done in the manner described earlier. After the space 
has been made available, the code of the method 1 47 
or 1 48 that is to be decompressed is decompressed by 
35 the code compressor in the available space and then 
invoked by the execution controller 153 in the manner 
just described (steps 410 and 406 of Figure 4). 

In view of the foregoing, it is clear that the described 
embodiment provides a reduction in run-time memory 
40 space while saving execution speed. This is due to the 
fact that by compressing the loaded methods 147 and/ 
or 148, they do not need not be flushed from the RAM 
136 and re-downloaded from the server computer sys- 
tems 104 when space in the RAM is needed. However, 
45 as those skilled in the art will recognize, other alternative 
embodiments could be implemented to provide similar 
benefits. 

Specifically, the compression criteria 1 52 described 
earlier specified that the code of least recently executed 

50 methods 147 and/or 148 with uncompressed code 
would be compressed when space in the RAM 1 36 was 
needed but not available. However, the compression cri- 
teria may be selected by the user from a broad range of 
options and based on a number of conditions specific to 

55 the user's client computer system 1 02. For example, the 
compression criteria may simply specify that the code 
of each method is to be compressed as soon as the 
method is no longer invoked. Or, it may specify that the 
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code of certain methods is to be compressed lazily 
whenever time is available for doing so. As an additional 
variation of any of the foregoing, the compression crite- 
ria may specify that only the code of methods of a spe- 
cific size or type is to be compressed. s 

Moreover, as was stated earlier, the decompression 
criteria 154 specified that a method 147 or 148 whose 
code is compressed code would have its code decom- 
pressed as soon as the method was to be invoked. How- 
ever, the decompression criteria could specify that the 10 
compressed code be decompressed after a predeter- 
mined time interval has expired. In this case, the data 
compressor would include a timer to time the time inter- 
val. In one example, this technique could be used for a 
method that is being put to sleep for a known time inter- is 
val so that the method will be compressed for this time 
interval and then decompressed just prior to when it is 
to be awakened. Or, in another example, the technique 
could be used for a method that is waiting for data where 
the time interval over which the method is compressed 20 
would be selected so as to predict when the data will 
become available for the method. 

In another embodiment, the compression criteria 
152 may also include flushing criteria specifying when 
the loaded methods 147 and/or 148 are to be flushed 2s 
from the RAM 136. For example, the flushing criteria 
may indicate that if there are no more loaded methods 
in the RAM that are not invoked and uncompressed, 
then the least recently executed method(s) in the LRI 
list 202 with compressed code are flushable and are to 30 
be flushed from the RAM 136 until enough space is 
made available. As a result; when a method is flushed 
from the RAM and then is to be executed again, the net- 
work communications manager 140 must re-download 
the program from the server computer system 104 that 35 
supplied the program in the manner discussed earlier. 
The execution controller 1 53 updates the program stor- 
age status table 200 by removing reference to any 
flushed methods. 

Since flushing loaded methods 1 47 and/or 1 48 from 40 
the RAM 136 is costly in terms of execution speed, a 
secondary memory 500 could be used to store the meth- 
ods that would otherwise be flushed, as shown in Fig- 
ures 5 and 6. In this case, the compression criteria 152 
discussed earlier would include secondary storage cri- 45 
teria that would be similar to the flushing criteria just d is- 
cussed and used to store methods that are storable be- 
cause they satisfy the secondary storage criteria. How- 
ever, in this case, the code compressor 146 would up- 
date the pointers in the program storage status table 200 so 
to point to these methods in the secondary memory. Fur- 
thermore, for the methods that are retrievable in that 
theircode is compressed, stored in the secondary mem- 
ory, and is to be decompressed, the code of the methods 
would- be retrieved from the secondary memory and 55 
then decompressed in the RAM 136 in the manner de- 
scribed earlier. 

Moreover, in an embodiment where the client com- 



puter system 102 includes a secondary memory 500 (e. 
g. a networked desktop computer), the methods 147 
and/or 148 could be downloaded from the server com- 
puter systems 104 to the secondary memory. Then, 
these methods could be loaded directly into the RAM 
136 from the secondary memory rather then from the 
server computer systems 104. Additionally, in such an 
embodiment, the operating system 138, the network 
communications manager 140, the virtual machine 
module 142, and the code compressor 146 could be 
stored in the secondary memory and loaded from there 
into the RAM. 

In still another embodiment, the operating system 
138, the network communications manager 140, the vir- 
tual machine module 142, and the code compressor 146 
could be downloaded from one of the server computer 
systems 104 into the RAM 136 of the dient computer 
system 1 02. This would be done in a similar manner as 
that described earlier for the methods 1 47 and/or 1 48 of 
a server computer system. 

In yet another embodiment, the virtual machine 
module 142 is actually implemented in a silicon chip and 
serves as the CPU 126 of the client computer system 
102. In this case, the methods 1 47 with AN code are not 
interpreted for a specific architecture and are instead 
executed directly. Inthis embodiment, methods 148 with 
AS code would not be utilized. 



Claims 

1. In a computer network over which is provided pro- 
grams with methods, a client computer system for 
executing the programs with reduced run-time 
memory space requirements, the client computer 
system comprising: 

an run-time memory; 

a network communications interface that re- 
ceives the methods; 

a network communications manager that loads 
the methods uncompressed into available 
space in the run-time memory when received; 
an execution controller that controls execution 
of the programs, whereby the methods are in- 
voked and not invoked at different times; 
a compressor that (A) compresses in the run- 
time memory compressible ones of the uncom- 
pressed methods that are not invoked, whereby 
space is made available in the run-time mem- 
ory, and (B) decompresses in available space 
in the run-time memory decompressible ones 
of the compressed methods so that the decom- 
pressible ones of the compressed methods 
may be invoked. 

2. The client computer system of daim 1 wherein the 
compressor decompresses the decompressible 



>OCID: <EP 0811911A2_L> 



7 



13 

ones of the compressed methods as soon as the 
decompressive ones of the compressed methods 
are to be invoked. 

3. The computer system of claim 1 wherein the com- 
pressor decompresses the decompressible ones of 
the compressed methods after a predetermined 
time interval. 

4. The client computer system of claim 1, 2 or 3, 
wherein the compressor compresses the com- 
pressible ones of the uncompressed methods as 
soon as the compressible ones of the uncom- 
pressed methods are no longer invoked. 

5. The client computer system ol claim 1, 2 or 3, 
wherein the compressor compresses the com- 
pressible ones of the uncompressed methods when 
space in the run-time memory is needed but not 
available. 

6. The client computer system of any of claims 1 
through 5 further comprising 

a least recently invoked list thnt lists those of 
the methods that aro curronily not invoked in 
order of least recently invoked method to most 
recently invoked motnod 
the compressible ones of the uncompressed 
methods are the least recently executed meth- 
ods in the least recently executed list that are 
not compressed when space in the run-time 
memory is needed but not available. 

7. The client computer system of any of claims 1 
through 6, wherein: 

the methods include methods in architecture 
neutral code that is independent of the archi- 
tecture of the client computer system; and 
the client computer system further comprises a 
virtual machine module that includes the exe- 
cution controller and enables execution of the 
methods in the architecture neutral code. 

8. The client computer system of any of claims 1 
through 7, wherein the compressor flushes from the 
run-time memory flushable ones of the compressed 
methods when space in the run-time memory is 
needed but not available. 

9. The client computer system of any of claims 1 
through 8 further comprising: 

a secondary memory; 

the compressor (A) stores in the secondary 
memory storable ones of the compressed 
methods when space in the run-time memory 



14 

is needed but not available, and (B) retrieves 
from the secondary memory retrievable ones of 
the compressed methods that are to be decom- 
pressed. 

5 

10. In a computer network over which is provided pro- 
grams with methods, a method of executing the pro- 
grams with reduced run-time memory space re- 
quirements, the method comprising the steps of: 

10 

providing an run-time memory; 
receiving the methods; 

loading uncompressed into available space in 
the run-time memory the methods when they 

75 are received; 

executing the programs, whereby the methods 
are invoked and not invoked at different times; 
compressing in the memory compressible ones 
of the uncompressed methods that are not in- 

20 voked, whereby space is made available in the 

run-time memory; and 

decompressing into available space in the run- 
time memory decompressible ones of the com- 
pressed methods so that the decompressible 
25 ones of the compressed methods may be in- 

voked. 

1 1 . The method of claim 1 0 wherein the decompressing 
step includes decompressing the decompressible 

30 ones of the compressed methods as soon as the 
decompressible ones of the compressed methods 
are to be invoked. 

12. The method of claim 10 wherein the decompressing 
35 step includes decompressing the decompressible 

ones of the compressed methods after a predeter- 
mined time interval. 

1 3. The method of claim 1 9, 1 1 or 1 2, wherein the com- 
40 pressing step includes compressing the compress- 
ible ones of the uncompressed methods as soon as 
the compressible ones of the compressed methods 
are no longer invoked. 

45 14. The method of claim 10, 11 or 12, wherein the com- 
pressing step includes compressing the compress- 
ible ones of the uncompressed methods when 
space in the run-time memory is needed but not 
available. 

so 

15. The method of any of claims 10 through 14 further 
comprising the steps of: 

providing a least recently invoked list that lists 
55 - . those of the methods that are currently not in- 
voked in order of least recently invoked method 
to most recently invoked method; 
the compressible ones of the uncompressed 
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melhods are the least recently invoked meth- 
ods in the least recently invoked list that are not 
compressed when space in the run-time mem- 
ory is needed but not available. 

16. The melhod of any of claims 10 through 15 further 
compnsinq the step of flushing from the run-time 
memory (lushable ones of the compressed methods 
when space m the run-time memory is needed but 
not Hvaitaolo 

17. The method of any of claims 10 through 16 further 
comprising the steps of: 

providing a secondary memory; 
storing ir, the secondary memory storable ones 
ot the compressed methods when space in the 
run-nrnc memory is needed but not available; 
and 

retrieving Irom the secondary memory retriev- 20 
abiu ones of the compressed methods that are 
to De decompressed. 

25 



30 



35 



40 



45 



50 



55 



9 

X)CID:<EP_. 081 1911 A2 I > 



10 



100 



EP0 811 911 A2 



102 



Client Computer 



System 



CPU 



JL 



134 



ROM 



M26 



4 



128 



^OBOooooooar 
/Boooodoooi/ 

User Interface 



Network Com. 
Int erface 

132- 7 " 



^136 



RAM 



Operating System 



Network Com. Manager 



Virtual Machine Module 



Execution Controller 



Code Verifier 



Code Compressor 



P rograms 



Methods: AN code 



Methods: AS code 



Execution Data 



Method Status Data Structures 



Criteria 



P-138 
140 
142 
153 
151 

146 

•145 

■147 

■148 

•149 

•155 
h-152, 154 



Client 




Computer 





•106 



Network Com. 
Connection 



110 



CPU 



Server 
Computer 
System 



104 



r 



104 



116 



Communications 
Interface 



Server Computer 
System 



4 



Is* 



112 



_oooaeooDD 
. aaoooBooor 
oaoaooooor 



User Interface 



118 



Operating System 



Network Com. Manager 



Programs 



Methods: AN code 



Methods: AS code 



•120 
•122 
•145 
•147 
-148 



Figur 1 



5DOCID: <EP 081191 1A2_I__> 



10 



EP0 811 911 A2 



102 



RAM 



Execution Data 



149 



136 



Method Status Data Structures 



155 



^202 



200 



LRI List 



Method 1 



Execution f\ 
Controller 



153 



146 



Method 


Location 


C/U 


Method 1 


PTRS 


C 


Method 2 


PTRS 


u 


• 
• 
• 


• 
• 
• 


• 
• 
• 


Method N 


PTRS 


u 



Virtual Machine 
Module 

151 



Code 
Verifier 



Code Compressor 



^•140 



Network Com. Manager |__ 
T 



Network Com. Interface "| 



147 



132 



Methods: AN code 



Methods: AS code 



148 



Method 1 : AN code 
Method 2: AS code 



-147 
•148 



Method N: AS code 



■148 



FIGURE 2 



_0811911A2J_> 



11 



EP0 811 911 A2 



300 




. ,3C 

| obtain methods 


)2 






^^^304 








spacers, 
available to load 
'^^methods?^^' 




306-^ , 


r 


v ^316 


load methods into 




compress method(s) in RAM 


available RAM space 


4 


until available space 



verity integrity 

of any 
methods with 
AN code 



307 



store exec, data in 
available RAM space 



324 



J 



compress method(s) in RAM 
until space available 



execute programs 
and invoke methodsHi 



314 



Yes 



space in RAM 
available for exec, 
ata of methods'? 



• 322 



326 



FIGURE 3 



3DOCID:<EP._ 0811 911 A2 I > 



12 



EP0 811 911 A2 



400 



402 



No, 



method to be 
invoked? 



404 

.Yes ^ method"^ No 
>mpressed2 



408 



Yes 



No 



space in RAM 



Yes 



. .2 


, 412^ 


^^decompressing 
^Nmethod?^^ 

410^ , 




compress method(s) in RAM 
until space available 




decompress method into 
available RAM space 


— » 



r 



I invoke method 



406 



FIGURE 4 



DOCID: <EP 081 1911 A2_L> 



13 



EP0 811 911 A2 



100 



102 



Client Computer 
System 



^134 



CPU 



ROM 



M26 



A 

£22. 



128 



aaODOOQDD 

oaaoDOQOor 
gpoDOOOOor 



oar 



User Interface 



Secondary 
Memory 



500 



37" 



Network Com. 
Interface 



132 



7 



_£136_ 



RAM 



Operating System 



Network Com. Manager 



Virtual Machine Module 



Execution Controller 



Code Verifier 



Code Compressor 



P rograms 



Methods: AN code 



Methods: AS code 



Execution Data 



Method Status Data Structures 



Criteria 



■138 
-140 
-142 
-153 
-151 

-146 
-145 
-147 
-148 
-149 
-155 
-h- 150, 152, 



154 



To/From Network 
Communications Connection 



FIGURE 5 



3DOC1D: <EP 081191 1A2J_> 



14 



EP0 811 911 A2 



RAM 



136 



200 



Method 


Location 


C/U 


Method 1 


PTRS 


! c 


Method 2 


PTRS 


c 


• 
• 
• 


• 
• 
• 


• 
• 


Method N 


PTRS 


u 



146 



Code Compressor 



Method 1: AN code 



Method N: AS code 



■147 



•148 



500 



Secondary Memory 



Method 2: AS code 



-148 



FIGURE 6 



1911A2_L> 



15 



(19) 



J 



Europaisches Patentamt 
Eur pean Patent Offlc 
Office europ 'en d s brevets 



(12) 



(88) Date of publication A3: 

10.03.1999 Bulletin 1999/10 

(43) Date of publication A2: 

10.12.1997 Bulletin 1997/50 

(21) Application number: 97303814.4 

(22) Date of filing: 04.06.1997 



(ID EP 0 811 911 A3 

EUROPEAN PATENT APPLICATION 

(51) Intel* G06F 9/45, G06F 9/46 



(84) Designated Contracting States: 


(72) Inventor: Lindholm, Timothy G. 


AT BE CH DE DK ES Fl FR GB GR IE IT U LU MC 


Palo Alto, California 94301 (US) 


NL PT SE 


(30) Priority: 05.06.1996 US 658472 


(74) Representative: 


Cross, Rupert Edward Blount et al 




BOULT WADE TENNANT, 


(71) Applicant: SUN MICROSYSTEMS, INC. 


27 Furnival Street 


Mountain View, California 94043-1100 (US) 


London EC4A1PQ (GB) 



(54) Computer system and method for executing network mobile code with reduced run-time 
memory space requirements 



(57) A client computer system and associated meth- 
od in a computer network over which are provided pro- 
grams with methods. The client computer is capable of 
executing the programs with reduced run-time memory 
space requirements. Specifically, a network communi- 
cations interface receives the methods of the programs 
and a network communications manager loads uncom- 
pressed in available space in the run-time memory the 
methods when they are received. An execution control- 



ler controls execution of the programs so that the meth- 
ods are invoked and not invoked at various times during 
execution of the programs. A compressor compresses 
in the memory compressible ones of the uncompressed 
methods that are not invoked so that space is made 
available in the run-time memory. The compressor also 
decompresses in available space in the run-time mem- 
ory decompressible ones of the methods so that they 
may be invoked. 



CO 
< 



o> 

1— 
00 

o 

UJ 



Printed by Jouve, 75001 PARIS (FR) 



DOCID: <EP 0811911A3_I_> 



EP0 811 911 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 97 30 3814 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
oj relevant passages 



Relevant 
to claim 



CLASSIFICATION Of THE 
APPLICATION (lnt.CI.6) 



"FAIL-SAFE MESSAGE FOR "INSUFFICIENT DISK 
SPACE"" 

IBM TECHNICAL DISCLOSURE BULLETIN, 
vol. 37, no. 4A, 1 April 1994, page 513 
XP000446759 

* the whole document * 

PATENT ABSTRACTS OF JAPAN 

vol. 016, no. 345 (P-1392), 27 July 1992 

6 JP 04 105129 A (NEC CORP), 7 April 1992 

* abstract * 

GB 2 284 492 A (SMITH GRAEME ROY) 

7 June 1995 

* page 1, line 1 - page 4, last line * 

EP 0 464 526 A (HEWLETT PACKARD CO) 

8 January 1992 

* page 2, line 1 - page 5, line 33 * 

* page 7, line 46 - page 9, line 7; figure 
2 * 

US 5 432 937 A (TEVANIAN AVADIS ET AL) 
11 July 1995 

* column 2, line 16 - last line * 

* column 4, last line - column 6, line 46 
* 



1,2,5,6, 

9-11,14 

15,17 



1,2. 
9-11,17 



1,2, 
9-11,17 



1,7,10 



G06F9/445 



The present search report has been drawn up for all claims 



TECHNICAL FIELDS 

(lnt.CI.6) 



1,10 



606F 



Place of watch 

THE HAGUE 



Date of comptotfon of the starch 

19 January 1999 



Examiner 

Bijn, K 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant tt taken alorta 

Y : particularly relevant fl combined *tth another 

document of the same category 
A : technological background 
O : non-written disclosure 
P : intermediate document 



T : theory or princfcle underlying the invention 
E : earlier patent document, but published on, or 

after the tiling date 
D : document cited in the application 
L : document cited for other reasons 



& ; member of the same patent family, corresponding 
document 



SDOCIO: <EP 081 191 1A3J_> 



2 



EP0 811 911 A3 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 97 30 3814 



This annex lists the patent family members relating to the patent documents cited in the above-mentioned European search report 
The members are as contained in the European Patent Office ED P file on 

The European Patent Office is in no way liable for these particulars which are merely given lor the purpose of information. 

19-01-1999 



Patent document 
cited in search report 



Publication 
date 



Patent family 
member(s) 



GB 2284492 



Publication 



07-06-1995 



NONE 



EP 0464526 



08-01-1992 



US 5280613 A 
DE 69125755 D 
DE 69125755 T 



18-01-1994 
28-05-1997 
18-09-1997 



US 5432937 



11-07-1995 



US 5604905 A 



18-02-1997 



i For more details about this annex : see Official Journal of the European Patent Office, No. 12/82 



5DOCID: <EP 081 1911A3J_> 



3 



